Home
Integrating
HCL Launch supports integrations with other IBM® products, products from others, and certain cloud systems.
Deploying components to the z/OS® platform
Use the toolkit to deploy to the IBM® z/OS® platform.
Creating z/OS® component versions
You can create z/OS component version by running the buztool.sh command from job control language (JCL) or from the z/OS® UNIX™ System Services command line. You can also create z/OS component version by using the z/OS File Source Config plug-in.
Merging z/OS component versions
Two or more z/OS component versions can be merged from a snapshot into one component version to simplify the deployment to the next environment. Merging component versions in this way avoids deploying intermediate programs into production.

Integrating
HCL Launch supports integrations with other IBM® products, products from others, and certain cloud systems.
- Integrating with HCL OneTest
  When you use OneTest™ Performance, you can create tests and run those tests in HCL Launch by using the HCL OneTest™ Performance Launch plugin.
- z/OS considerations for HCL Launch
  HCL Launch includes support for the z/OS platform. Although the articles in this Knowledge Center for using HCL Launch to deploy applications, certain platform-specific configuration factors must be considered when using a z/OS model.
- Deploying components to the z/OS® platform
  Use the toolkit to deploy to the IBM® z/OS® platform.
  - Ship list files
    The ship list file describes the files from the build to include in the new component version to deploy. Ship list files can also use generic artifacts to describe changes that are not physical files, such as configuration changes.
  - Generating Ship list for Endevor and Changeman packages
    You can generate shiplist.xml using Endevor SCL and Changeman configurations. Generated shiplist.xml can later be used to create component version using buztool.sh.
  - Searching the z/OS environment inventory
    The z/OS search feature is available for any application that contains a z/OS type component. Search is performed for a specific file in the artifacts belonging to the z/OS components deployed to that environment.
  - Creating z/OS® component versions
    You can create z/OS component version by running the buztool.sh command from job control language (JCL) or from the z/OS® UNIX™ System Services command line. You can also create z/OS component version by using the z/OS File Source Config plug-in.
    - Creating z/OS® component versions from JCL
      To create IBM® z/OS® component versions from job control language (JCL), create and submit JCL to run the buztool.sh command.
    - Creating z/OS® component versions from z/OS® UNIX™ System Services
      To create IBM® z/OS® component versions from z/OS UNIX™ System Services, submit the buztool.sh command from a z/OS UNIX shell.
    - Creating z/OS® component version using the v2 package format
      Starting with HCL Launch version 7.0.5, you can create IBM® z/OS® component versions from a new package version called version 2 or v2. You can create v2 component versions using the buztool.sh command.
    - Merging z/OS component versions
      Two or more z/OS component versions can be merged from a snapshot into one component version to simplify the deployment to the next environment. Merging component versions in this way avoids deploying intermediate programs into production.
  - Security requirements on IBM® z/OS® computers
    Specific security definitions are used to secure HCL Launch functions for the IBM® z/OS® environment. To deploy applications to an IBM z/OS environment, the user accounts on the agent computer must have adequate access permissions. You must also identify specific directories and data sets to the authorized program facility.
  - Troubleshooting problems on z/OS®
    To troubleshoot problems on agent computers that are running IBM® z/OS®, examine the agent log files.

Merging z/OS component versions

Two or more z/OS component versions can be merged from a snapshot into one component version to simplify the deployment to the next environment. Merging component versions in this way avoids deploying intermediate programs into production.

Before you begin

Note the following items when you merge z/OS components.

Only incremental versions of z/OS components can be merged.
Only versions stored in the CodeStation can be merged. The merged version is also stored in the CodeStation.
Merging of versions is not supported when any of the z/OS versions have HFS artifact (shiplist type as directory and file).
Only data sets are merged into the new version.
When two or more versions contain the same artifact, the artifact from the latest version in the snapshot is used.
All customer properties on containers are added to the container in the merged version. This might lead to deployment failures if the deployment process relies on properties on containers.
The merged version has version properties from the last version in the snapshot.

Merge z/OS component versions workflow

Procedure

Create a snapshot from an new or existing environment.
Add or delete versions in the snapshot's Component Versions view. The Component column lists the merged artifacts from all the selected versions. The Versions column displays all the versions that contain the artifacts.
From the Actions menu, click Merge for the selected components and supply a name for the merged version. Click Save. A new version is created from the merged content of the selected versions.
In the Artifacts view, click Show SYS properties. The source version name and ID are displayed.

Results

The following outcomes apply to merged versions.

Deployment, backup, and restore actions of merged versions proceed like any other version. No change is required in the deployment process.
Deleting or archiving the original version has no impact on the merged version.
A merged version can be merged with other versions again.
Properties that you set on a Partitioned Data Set (PDS) are added from all versions to the PDS in the merged version for the same properties. The later value for the property overwrites the former value.
Note: Overwriting PDS properties might lead to deployment failures if your deployment process relies on the properties that you set in the PDS.